On-Premises Content Inspection Azure Deployment Procedure

This document outlines the Azure-specific setup procedure for Content Inspection on-premises deployment.

Customer Requirements

Infrastructure Prerequisites

• Azure Kubernetes Service (AKS) cluster with minimum node specs (4 vCPUs, 16GB RAM per node)
• Working Ingress controller (Application Gateway or nginx recommended)
• Permissions to create Azure AD applications, managed identities, role assignments, and storage accounts

Required Tools

• az CLI, kubectl, helm

Part 1: Customer Prerequisites

Complete these steps before contacting Cyberhaven for SaaS configuration.

1. Prepare External Identity Provider

APPLICATION_ID=$(az ad app create --display-name "cyberhaven-ci-stack" --query appId -o tsv)
APPLICATION_ID_URI="api://$APPLICATION_ID"
az ad sp create --id "$APPLICATION_ID"
az ad app update --id "$APPLICATION_ID" --identifier-uris "$APPLICATION_ID_URI"

echo "Application ID URI: $APPLICATION_ID_URI"

Reference: Azure Workload Identity Federation Documentation

2. Setup Workload Identity and OIDC

RESOURCE_GROUP="MyResourceGroup"
LOCATION="eastus"  # Adjust as needed
IDENTITY_NAME="cyberhaven-ci-stack"
CLUSTER_NAME="MyCluster"

# Create managed identity
az identity create \
  --name "$IDENTITY_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --location "$LOCATION"

# Enable Workload Identity and OIDC issuer on AKS cluster
TENANT_ID=$(az account show --query tenantId -o tsv)

az aks update \
    --resource-group "$RESOURCE_GROUP" \
    --name "$CLUSTER_NAME" \
    --enable-workload-identity \
    --enable-oidc-issuer
    
CLIENT_IDENTITY_ID=$(az identity show \
     --name $IDENTITY_NAME \
     --resource-group "$RESOURCE_GROUP" \
     --query clientId \
     --output tsv)

OIDC_ISSUER_URL=$(az aks show \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --query "oidcIssuerProfile.issuerUrl" \
    --output tsv)

STS_ISSUER_URL="https://sts.windows.net/$TENANT_ID/"

echo "STS Issuer URL: $STS_ISSUER_URL"
echo "Client Identity ID: $CLIENT_IDENTITY_ID"

Reference: AKS Workload Identity Documentation

3. Create Federated Identity Credential

Create a single federated credential for the consolidated CI stack service account:

NAMESPACE="default"  # Adjust if deploying to different namespace
SA_NAME="ci-stack"   # Consolidated service account name

az identity federated-credential create \
    --name $SA_NAME \
    --identity-name "$IDENTITY_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --issuer "$OIDC_ISSUER_URL" \
    --subject "system:serviceaccount:$NAMESPACE:$SA_NAME" \
    --audience "api://AzureADTokenExchange"

Note for Existing Deployments: If you have existing separate federated credentials for dlp-coordinator, dlp-tika, etc., you can consolidate them into a single credential or reuse the existing dlp-coordinator credential by setting SA_NAME="dlp-coordinator".

4. Setup Azure Blob Storage

STORAGE_ACCOUNT_NAME="yourstorageaccount"  # Must be globally unique
CONTAINER_NAME="files-cache"

# Create storage account (if not existing)
az storage account create \
  --name "$STORAGE_ACCOUNT_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --location "$LOCATION" \
  --sku Standard_LRS

# Create container
az storage container create \
  --name "$CONTAINER_NAME" \
  --account-name "$STORAGE_ACCOUNT_NAME" \
  --auth-mode login

# Grant blob access to managed identity
STORAGE_ACCOUNT_ID=$(az storage account show \
    --name $STORAGE_ACCOUNT_NAME \
    --resource-group $RESOURCE_GROUP \
    --query id --output tsv)
CONTAINER_ID="$STORAGE_ACCOUNT_ID/blobServices/default/containers/$CONTAINER_NAME"
PRINCIPAL_ID=$(az identity show \
  --name $IDENTITY_NAME \
  --resource-group $RESOURCE_GROUP \
  --query principalId --output tsv)

az role assignment create \
  --assignee-object-id $PRINCIPAL_ID \
  --role "Storage Blob Data Contributor" \
  --scope $CONTAINER_ID

echo "Container ID: $CONTAINER_ID"

5. Verify Ingress Controller

Ensure your ingress controller is working. For Application Gateway:

• AKS Application Gateway Documentation
• Test with a simple ingress resource

Information to Share with Cyberhaven

Provide these values to Cyberhaven for SaaS configuration:

• Application ID URI: $APPLICATION_ID_URI
• STS Issuer URL: $STS_ISSUER_URL
• Client Identity ID: $CLIENT_IDENTITY_ID
• Namespace: $NAMESPACE

---

Part 2: Post-SaaS Configuration

Complete these steps after Cyberhaven configures the SaaS environment and provides you with the workload identity federation configuration.

1. Configure Helm Values

Update values/customer-values.yaml with your Azure-specific settings:

global:
  customer:
    provider:
      type: "azure"
      clientId: "12345678-1234-1234-1234-123456789012"  # Your CLIENT_IDENTITY_ID
    cache:
      type: "azblob"
      name: "files-cache"
    ingress:
      enabled: true
      className: "webapprouting.kubernetes.azure.com"  # or nginx
      annotations:
        nginx.ingress.kubernetes.io/proxy-body-size: "25m"
        nginx.ingress.kubernetes.io/proxy-read-timeout: "200"
    azureConfig: |
      {
        # Azure-specific configuration provided by Cyberhaven
      }
    saas:
      googleCredentials: |
        {
          # Workload identity federation JSON provided by Cyberhaven
        }

2. Deploy

Follow the standard installation procedure from INSTALL.

Validation

After deployment, verify:

1. Pod Status: All pods reach Running state
2. Blob Storage Access: CI components can read/write to storage container
3. SaaS Connectivity: Monitor for successful request processing

Troubleshooting

Workload Identity Issues: Verify OIDC issuer, federated credentials, and service account annotations Blob Storage Access Denied: Check managed identity permissions and role assignments Ingress Issues: Verify ingress controller configuration and network security groups

For issues, collect pod logs and run make status before contacting support.

Migration from Legacy Setup

If upgrading from previous versions with separate federated credentials:

1. Option A (Recommended): Consolidate into single federated credential for ci-stack service account
2. Option B: Reuse existing dlp-coordinator federated credential as consolidated identity
3. Remove separate federated credentials for dlp-tika, ci-scanner, and dlp-ocr (if they exist)
4. Update Helm configuration to use consolidated service account name

This consolidation simplifies identity management while maintaining security.